home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3271 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.3 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Amiga doesn`t need Planar!
  5. Date: 10 Feb 1996 10:41:09 +0100
  6. Organization: dis-
  7. Message-ID: <4fhp7l$kaa@serpens.rhein.de>
  8. References: <john.hendrikx.4coj@grafix.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  12.  
  13. >So isn't it true that Chunky is quite useable with a lot less hardware?
  14.  
  15. Obviously. I never denied that for planar hardware you need a kind of
  16. "planar CPU" that can deal with it.
  17.  
  18. > MVE> You mean the x * 100MByte/s of memory bandwidth on the graphics card
  19. > MVE> is slow ?
  20.  
  21. >So what is 'x'?  Without it this statement could mean anything.
  22.  
  23. With current cards that's something between 2 and 8.
  24.  
  25. >However, the bus TO the gfx-card is slow, so doing a few extra tests'and
  26. >branches for each pixel plotted would not make things any slower, and thus
  27. >wouldn't be a big overhead, like you claimed in the first place.
  28.  
  29. Again you just think about a CPU and a graphics card. But real rendering
  30. hardware sits on the board just like a blitter.
  31.  
  32. >If the hardware limits you to some arbitrary number of colors when it comes to
  33. >layering displays then you can be glad that the display is Chunky as this kind
  34. >of display can do quite rapid layering of its own without losing any colors.
  35.  
  36. A chunky display can NOT do layering of its own without losing any
  37. colors.
  38.  
  39. >better choose carefully what hardware to use.  I mean, if you require a fast
  40. >256 color 3d view, with a cockpit overlayed then you either chose a 8-bit
  41. >Chunky card, or a 9-16 bit Planar card.
  42.  
  43. Of course that's not equivalent. The chunky version would need more CPU
  44. time for the layering while it comes automatic with the deeper (planar)
  45. display. Again, that has little to do with chunky vs. planar. Think
  46. about 16bit chunky (and that would be a 16bit _paletted_ display as with
  47. the planar example). You can write single bytes of a pixel and get
  48. exactly the same effect as with planar.
  49.  
  50. >Special hardware can only do what is popular, the latest effects will still be
  51. >CPU based at first before they become popular, IF they become popular that is.
  52.  
  53. Actually the "latest effects" will probably happen on the most popuplar
  54. computer.
  55.  
  56. > MVE> You mean the $10 DSP that handles the audio ports ? Or the $100 DSP
  57. > MVE> that decodes the network video streams ?
  58.  
  59. >Why not add a $80 PPC603/66 and get an overall speed boost,
  60.  
  61. You mean a $80 PPC603/66 that can hardly do what the $10 DSP can do and
  62. that is too underpowered to do what the $100 DSP can do ?
  63.  
  64. >handling video streams, or the things the OS uses the DSP for.  For most users
  65. >this will safe them more time on overall.
  66.  
  67. Not if they are interested in what the DSPs do.
  68.  
  69. > MVE> Usually it is weaker than special hardware and hardly used too.
  70.  
  71. >Depends on the OS.  It would be hard to get a single-processor based OS to make
  72. >good use of multiple processors, but if it is was there right from the
  73. >beginning the benefits could be quite high.
  74.  
  75. The best you can get is to multiply the base speed by the number of
  76. processors.
  77.  
  78. >Tasks involving frequent Harddisk
  79. >access for example divide their CPU power over 3 different tasks in AmigaOS
  80. >already.
  81.  
  82. Which would run a zilch better on multiple CPUs because these tasks
  83. rarely run together and rarely utilize the CPU.
  84.  
  85. >And almost any task can be split over multiple CPU's with a bit of
  86. >forethought.  But it would be hard to add now, and make decent use of it, even
  87. >though it is never too late to start as I think multiprocessor designs are
  88. >going to move into the homes real soon now.
  89.  
  90. Sure. Doesn't magically make it cheaper than an equivalent faster CPU.
  91. The architecture of a multiprocessor isn't simple, especially when you
  92. go beyond 2 CPUs.
  93.  
  94. >Also, why would CPU + DSP be faster at TMap + MPEG than 2 CPU's?  The CPU doing
  95. >the TMapping might actually have time left to help with the MPEG decoding.
  96.  
  97. This depends on the CPUs... usually a DSP outperforms general purpose
  98. CPUs in these tasks (even when DEC claims the opposite if you use Alphas).
  99.  
  100. So if you want to do signal processing you better have some hardware
  101. that does it. If you want a more flexible solution then you might start
  102. with multiple CPUs, but don't expect it to be cheap.
  103.  
  104. >They will be stored one by one in the pattern buffer, maybe storing a few in
  105. >registers before writing them to the pattern buffer, but the loop which
  106. >calculates the pixels will clearly be working at one pixel at the time.
  107.  
  108. Read below.
  109.  
  110. > MVE> pixels might be computed individually but these are hardly _drawn_
  111. > MVE> individually.
  112.  
  113. >"Drawn" to me means writing them to memory.  For me the C2P step is not the
  114. >thing which draws the scene to the screen, instead the TMapping routine which
  115. >builds the Chunky buffer is the thing that draws them.
  116.  
  117. What chunky buffer ? :)
  118.  
  119. >For Planar the hardware determines how cool the effects can be, and determines
  120. >the maximum speed as well.  The CPU is not involved.
  121.  
  122. Why not ?
  123.  
  124. >hardware speeds and CPU speeds of the same age.  The speed difference is so big
  125. >that the CPU can afford to do a complete C2P conversion to get new cool effects
  126. >to be used with the old planar system.
  127.  
  128. And that's what you think about graphics systems all the time.
  129. -- 
  130.                                 Michael van Elst
  131.  
  132. Internet: mlelstv@serpens.rhein.de
  133.                                 "A potential Snark may lurk in every tree."
  134.